Scenarios for device attachment defined in the current ETSI M2M standards include:
A set of service capabilities (Service Capabilities, SCs), which is also called a service capability layer (Service Capability Layer, SCL), and is an M2M capability middleware.
An M2M device without SCL capability, i.e., a Ds device, where the Ds device cannot directly communicate with an M2M platform but only can communicate with the M2M platform via a gateway device.
An M2M device with SCL capability, i.e., a D device, where the D device can directly communicate with the M2M platform.
G gateway: M2M gateway device, which directly manages the Ds device, and can directly communicate with the M2M platform.
Gs gateway: M2M gateway device, which can simultaneously manage the Ds device and the D device, and can directly communicate with the M2M platform.
DA: a device application, which is stored in the D device and the Ds device.
GA: a gateway application, which is stored in a G device and a Gs device.
A network application (Network Application, NA), which can be independent of the M2M platform and configured on other server. The server where the NA is located is called a network application server in the subsequent description.
Resources of the M2M platform are managed in a tree-like manner. The M2M platform manages resources corresponding to multiple devices, and the whole resource tree strictly corresponds to a network topology structure of all devices in the current network. For example, catalog DSCL1 under catalog scls indicates resources corresponding to a D device, while the catalog GSCL1 corresponds to resources of a G gateway. Generally, a typical device resource can be represented by a URI as follows:
http://m2m.myoperator.org/sclBaseN1/scls/DSCL1/applications/DA1/accessRights/ar1/permissions
In a current device attachment scenario, there may be two kinds of scenarios where the device attachment changes, in view of saving subscriber's communication cost or improving communication quality of signals: scenario 1: the D device switch to Ds device or the Ds device switch to D device; scenario 2: the D device or the Ds device roams between different gateways, or the D device roams between the platform and the gateway (namely, the D device attaches to the platform via the gateway instead of directly attaches to the platform). As for scenario 1, capability of the device itself changes, the D device turns off its SCL capability, and then switches to a DS device, vice versa; as for scenario 2, capability of the device itself doesn't change, and an only difference is the attach point the device uses.
As for the above two scenarios where attachment changes, normally, the device needs to be de-registered first in the system using a de-registration process provided by the ETSI standard, and then registered in the system using a registration process provided by the ETSI standard, and after that the changing of the device attachment can be completed. However, such processing has a problem that a network topology structure may change after the device attaches, which will cause the change of the position of the device in the resource tree, therefore the network application server cannot accurately access resources of the re-registered device.